Part of JETPACK-1504

Proposed Changes

#109765 added the simplified Jetpack footer to four Calypso pages (Activity Log, Monetize, Traffic, Podcasting) but explicitly left Backup and Scan out due to the additional complexity of testing them. This PR closes the Backup half across all WP.com render paths reachable from /backup/<site-slug>.

Files touched

• client/my-sites/backup/main.jsx — happy-path BackupPage (when the site has the backup product). Footer gated on isWpcom. Pattern matches Podcasting (client/my-sites/site-settings/podcasting-details/index.jsx) which uses the same <Page> from @wordpress/admin-ui and renders <JetpackFooter /> after </Page> but inside <Main>.
• client/my-sites/backup/wpcom-backup-upsell.tsx — WPCOMUpsellPage reached via the showUpsellIfNoBackup / showUpsellIfNoBackupRestoreFeature middlewares (client/my-sites/backup/index.js) when the site has no backup product or feature. File is wpcom-only by construction (Jetpack Cloud uses a separate backup-upsell component) so no isJetpackCloud() gate is needed.
• client/my-sites/backup/wpcom-upsell.tsx — WPCOMUpsellPage reached via WPCOMBusinessAT on Business-plan WP.com sites that lack WPCOM_FEATURES_BACKUPS_SELF_SERVE. Same wpcom-only construction.
• client/components/jetpack/wpcom-business-at/index.tsx — shared Atomic-transfer component used by both Backup and Scan. Footer added on both <Main> branches (the featuresNotLoaded placeholder and the transfer CTA), gated on ! isJetpackCloud() because the same component is also rendered by Jetpack Cloud paths. Side effect: this fix also benefits Scan's atomic-transfer flow as a free side-effect, since the component is shared.

Total diff is 9 added lines across 4 files (one import + one render line per file, with the wpcom-business-at file getting two render lines for its two <Main> branches).

Render path coverage

Backup's route middleware chain (client/my-sites/backup/index.js line 97-114) means /backup/<site> can resolve to one of several components depending on the site's plan/features and whether it's WP.com Simple, WP.com Atomic, or Jetpack Cloud:

Out of scope: UpsellSwitch loading flash

client/components/jetpack/upsell-switch/index.tsx wraps its placeholder children in a <Main className="upsell-switch__loading"> during the brief moment between mount and the "do we have a backup product?" data load. This <Main> has no footer, so there's a momentary flash before the loaded state takes over.

This PR intentionally does not modify UpsellSwitch because it's generic Jetpack-feature shared infrastructure used beyond Backup (Anti-Spam, Search, etc.). Adding a footer there would change loading-state appearance for every feature using it, which is a much broader discussion than HEADER-008's scope. Worth its own ticket if we want loading-state footers everywhere.

Why are these changes being made?

#109765 added the simplified Jetpack footer to four Calypso pages (Activity Log, Monetize, Traffic, Podcasting) but explicitly left Backup and Scan out — quoting that PR's description:

Using the footer at Scan & Backup I'm also leaving for another PR due to a bit more complexity of testing those pages, so this is easier to merge sooner.

This PR closes the Backup half. Scan will follow in a sibling PR (#109888). After both land, JETPACK-1504's checklist will be complete and the parent issue (JETPACK-1391) can tick its remaining Calypso boxes.

Testing Instructions

Before / After (happy path, main.jsx)

Before: Backup page ends right at the bottom of the "More backups from today" card with empty white space below it — no footer chrome.

After: Same content with a new row at the bottom showing the green Jetpack pill on the left and the "An Automattic airline" byline on the right, matching the existing footer on Activity Log / Monetize / Traffic / Podcasting.

Steps to verify

1. Happy path: On a WP.com site with Jetpack Backup active, navigate to /backup/<site-slug>. Expected: footer renders at the bottom of the page.
2. Upsell path (Simple): On a WP.com Simple site without Backup, navigate to /backup/<site-slug>. The page renders the upsell (WPCOMUpsellPage from either wpcom-backup-upsell.tsx or wpcom-upsell.tsx depending on the plan/feature combo). Expected: footer renders at the bottom.
3. Atomic transfer path: On a Business-plan WP.com site that triggers the Atomic transfer flow, navigate to /backup/<site-slug>. Expected: footer renders below both the loading placeholder and the transfer CTA.
4. Jetpack Cloud variant (if available): Navigate to the same Backup page from the Jetpack Cloud variant and confirm the footer does not render — Jetpack Cloud has its own chrome and the isWpcom / isJetpackCloud() gates suppress the new footer for that platform.
5. Switch to a narrow viewport (≤460px) and confirm the footer wraps cleanly.

DOM check

Quickly verifiable from the browser console:

document.querySelector( 'footer.jetpack-footer' )
// → <footer class="... jetpack-footer" aria-label="Jetpack" role="contentinfo">…</footer>

To confirm there's no duplicate footer rendering:

document.querySelectorAll( 'footer.jetpack-footer' ).length
// → 1

Local validation already performed

Desktop:

• ✅ willstestdotblog.wordpress.com (Simple, no backup → upsell render path via WPCOMBusinessAT → wpcom-upsell.tsx): footer present after fix; absent before
• ✅ curlingforbeginners9.wpcomstaging.com (Atomic with backup → main.jsx happy path): footer present, footerCount === 1 (no duplicate from the upsell-switch display prop chain)

Mobile viewport (390×844, ≤460px breakpoint):

• ✅ Simple upsell path on willstestdotblog.wordpress.com: footer renders below the "What is Jetpack?" section at the bottom of the page, wraps cleanly, single instance
• ✅ Atomic happy path on curlingforbeginners9.wpcomstaging.com: footer renders below the backup activity cards, wraps cleanly, single instance

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes? — N/A, wiring change with no logic to test
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)? — Simple verified on willstestdotblog.wordpress.com, Atomic verified on curlingforbeginners9.wpcomstaging.com. Self-hosted Jetpack n/a (this code path is wpcom-only by construction).
• Have you checked for TypeScript, React or other console errors? — none in local build; pre-commit Prettier ran clean
• Have you tested accessibility for your changes? Ensure the feature remains usable with various user agents (e.g., browsers), interfaces (e.g., keyboard navigation), and assistive technologies (e.g., screen readers) (PCYsg-S3g-p2). — <footer role="contentinfo" aria-label="Jetpack"> inherits the same a11y as the existing JetpackFooter usages
• Have you used memoizing on expensive computations? — N/A, no new computations
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)? — no new strings; the footer's "Jetpack" / "An Automattic airline" labels live in JetpackFooter itself and are already translated
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? — N/A, no new strings
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)? — no, no tracking or data changes